COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	DIALnet memo #4
C00004 00003	     All protocol  communication in  the  non-interactive higher  level  Dialnet
C00007 ENDMK
C⊗;
DIALnet memo #4
SAILON sail on, sail on

















			       DIALnet Protocols

			  (or, the Protocols of DIAL)

		 Format for Non-Interactive Tertiary protocols

				  John McCarthy

				    12/13/77

























     These protocols are being developed as  part of the DIALnet project at  the
Stanford University Artificial  Intelligence Laboratory supported  by NSF  grant
MCS 77-02080  with John  McCarthy  as Principal  Investigator.  The  project  is
described  in   a   paper   available   online  at   ARPAnet   host   SU-AI   as
DIALNE.MEM[DLN,MRC] (DIALnet Memo #1).

     This is FORMAT.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
     All protocol  communication in  the  non-interactive higher  level  Dialnet
protocols (e.g. MAIL,  File Transfer)  uses a  list format  for messages.   Each
message therefore has the form

     (<identifier> <item> ... <item>)

     where the  items  themselves  are  either identifiers  or  have  a  similar
structure.  The object of this scheme is to ensure flexibility.

     Suppose, for  example,  that  one  of  the  items  in  a  protocol  message
designates a user name.  Initial designs  of Dialnet may allow only a  character
string without parentheses like SMITH to  designate the user.  Later this  might
be elaborated  to also  allow a  complex designator  like (SUCCESSOR  SMITH)  to
designate the person who has replaced SMITH in this job assignment.

     There is no present intention that the Dialnet protocols will be subject to
rapid elaboration.  The  present object is  merely to build  these protocols  so
that they will not be  subject to blind alleys.   Therefore, there are no  fixed
size fields, and item that is initially represented by an atomic name may  later
be replaced by some kind of expression, and new terms may be adjoined to  lists.
Thus if  an item  is  presently denoted  by a  three  term list,  an  elaborated
protocol may later call for a four item list, but if the same initial identifier
is used, it should still be possible  for a recipient to ignore the fourth  item
and still use the message.

     We  believe   that   these  conventions,   at   slight  cost   in   initial
implementation, will make future improvements easy should they be required.